The present invention relates to data storage systems. More specifically the present invention relates to obtaining file system view in block-level data storage systems.
A block level storage controller (e.g. Storage Area Network—SAN—controller) controls communications between a host and data storage, using a block-level protocol. The SAN block storage controller interacts with hosts via block-level protocols, such as iSCSI and Fibre Channel (FC). Usually, block-level storage systems do not maintain information specific to the file-system using them. A file system view at the controller, together with the knowledge of which arriving block belongs to which file or mode may leverage many controller applications, such as, for example, storage based intrusion detection that may handle file level threats, semantic data replication, online backup and fine-tuned monitoring. Such view may supply knowledge of association between blocks and the corresponding file to which these blocks belong, and also allow ongoing inference of file-level commands.
An intrusion detection system (IDS) is an appliance or application that monitors network and/or system activities for malicious activities or policy violations. There are two main types of IDS systems: network-based and host-based IDS. In network-based IDS, sensors are located at points in the network to be monitored. The sensors capture all network traffic and analyze the content of individual packets in order to detect malicious traffic. In a host-based system, the sensor usually is a software agent that monitors activity of the host on which it is installed, including file system, log files and the kernel. In storage-based IDS, a sensor captures all the traffic (I/O requests) that arrives at the storage controller, and analyzes possible storage system violations or threats. The very few storage systems that do maintain online IDS are accessed via file-level protocols, such as CIFS or NFS. Application of a block level storage based IDS seem to be far more complicated and does not exist to-date.
Several ways have been suggested to facilitate a file system view at the controller. However these suggestions interfere with the controller I/O path, an approach that suffers from several limitations. First, adding software to the modules that handle the I/O path of a controller is a complicated and error-prone task with heavy development expenses. Second, the CPU capacity at the controller is designed to handle the arriving I/O requests and may not be able to perform additional computation tasks that are required in order to obtain the file-view. Finally, it is much more appealing to add a new external appliance, rather than replacing or patching the existing system.